Planning Project Settings

Your application recognizes two types of underground planning project:

A Master Project: A container for sub-projects (see below).

Master projects generally represent the view of operations at a high level, linking together smaller sub-projects with the same project settings. Master projects can include dependency links between activities of different sub-projects.
- Master projects can't be used to set up design attributes and definitions, nor can they be used to validate or process designs to generate solids.
- Master projects can be used to define dependencies (potentially between different sub-projects). See Planning Dependencies.
- Master projects can be used to connect to an EPS instance and write to / read from an EPS schedule. See Transfer Data to EPS.
- Master projects can be used for reporting and dashboarding.
More about master project settings...
A Sub-project: A part of a larger organizational underground planning project, or a standalone project.

Sub-projects can be associated with a master project (see above) and are used independently to define schedule settings (filters, interrogation and depletion, naming convention etc.), design definitions, attribution, validation, processing, dependencies, EPS connection, reporting and dashboarding. These setting typically relate to a single planning scenario.

You don't have to create a master project: if your project can be fully-defined within a single project, a sub-project is all you need. This can, if needed become part of a master project later. For example, a single, standalone project can be used to represent the underground life of mine but as the scope of excavation is extended later (say, as a result of a rising commodity price), a master project may be required to bring in the data from previously-unplanned partner operations.

More about sub-project settings

Choose which project type you are using via the Utilities panel.

Note: Project settings for master and sub projects must be identical. You cannot import (and subsequently process or define a schedule for) sub-projects with different project settings.

Tip: Create a template sub-project to define your project settings (filters, conventions, attributes, design definitions and so on) then copy this to create new sub-projects. This will ensure all settings are compatible when imported to a master project later.

Master Projects and Sub-Projects

By default, your application will create a sub-project, enabling access to all underground planning functionality on the Planning ribbon.

Sub projects provide full access to project settings. This behaviour represents legacy versions of Studio UG, prior to the existence of master project functionality. As such, the Settings panel for a sub-project provides differing functionality to that of a master project.

If a sub-project is active, the Planning ribbon can be fully-enabled, meaning you can set up you project details, definitions and so on independently. Generally, each sub-project represents one aspect of the master underground plan.

Once a sub-project has been defined, it can be imported to a master project (using a modified form of the Settings panel - see below). All data inputs and configuration will be imported, replacing any previously-imported instance of the same sub-project.

A master project is, essentially, a container for settings and cross-project manual dependencies. It is important that the settings for the master project are appropriate for all sub-projects as the master project settings will be used for all collated sub-project processing.

As some planning functionality is only relevant (= stored within) a sub-project, when a master project is active, some ribbon functionality is disabled, including:

The Design panel;
The Definitions panel
The Validation panel
The Process panel

In summary, master projects link sub-projects together. Sub-projects are added to a master project through an importation process (this is done using a special version of the Settings panel).

Updating an Imported Sub Project

Once a sub-project has been imported to a master project, the workflow for subsequently updating it and updating the master schedule is:

Edit the sub-project and test the output and save it.
Open the master project
Re-import the sub-project
- Dependencies that go between two activities within the same sub-project will be purged, regardless of whether they were imported or created in the master project
- Dependencies that go between an activity in the sub project being purged and an activity in another sub project will be saved during the purge and an attempt will be made to restore them if the activities still exist
Recreate any manual dependencies between the sub project and another sub project, if they previously existed (they will have been removed during re-import).
Save the master project

What happens after a sub-project is imported?

Once a sub-project has been imported to a master project, all data inputs for the sub-project are copied to the appropriate database folder of the master project. There is no ongoing dynamic link between the sub-project and the master project.

This means that subsequent changes to the data (or settings) of the sub-project will need to be synchronized with the master project by either re-importing the sub-project (to bring in data changes made in the sub-project) or settings adjustment in the master project (which will affect all imported sub-projects).

Certain aspects of sub-projects must be consistent if imported to a master project. This is because a master project is used to assemble all the components of a production schedule, commonly for export to Enhanced Production Scheduler (EPS). To do this, a single collection of design definitions, attributes and other project items are needed.

As such, a comparison of all sub-projects is made during import to ensure, where a common definition is required, it is present in all sub-projects. This applies to the following project components:

Filters
Attributes
Properties
Design definitions
Dependency layers
Spatial dependency rule sets
Attribute dependency rule sets

Otherwise, settings that relate purely to a sub-project (such as naming conventions, interrogation rules, and input design data files) will be imported to the master project using the Utilities panel function.

Warning: Converting a sub-project to a master project will remove project settings and is not reversible. You should make a backup of your sub-project before converting it to a master project.